This section is intended to introduce the reader to various aspects of the art that may be related to various aspects of the present invention. The following discussion is intended to provide information to facilitate a better understanding of the present invention. Accordingly, it should be understood that statements in the following discussion are to be read in this light, and not as admissions of prior art.
SIGTRAN WG of IETF has defined a set of protocols that enable transport of signaling protocols, such as SS7, V5, DSS1. DPNSS or Q-SIG, over IP networks.
Some of SIGTRAN xxUAs in addition to the concept of Application Server and Routing Key based on SS7 addressing parameters use special mechanisms that allow identifying traffic allocated to particular Signaling Processes, and traffic, which has not been allocated to any signaling process yet, for example SUA defines TID and DRN Labels, which can be provided in ASPTM ACTIVE message to indicate that the signaling process is able to process traffic for particular ranges of destination TIDs and DRNs: SUA messages that do not contain a destination TID or a DRN relate to non-allocated traffic and can be load-shared between the active processes for the concerned application server.
Some SIGTRAN implementations can perform load-sharing of SIGTRAN traffic using a weighted round robin method, the traffic is load-shared between the active processes of the concerned application server. Active signaling Processes having the weight of zero for an application server are not sent any traffic, unless all other active signaling processes have weight zero too.
Existing SIGTRAN standards and implementations do not allow for graceful change of signaling process states from ACTIVE to INACTIVE or DOWN, that is, there is no procedure defined by SIGTRAN protocols that allows for graceful changeover of traffic distribution from signaling process that intend to go INACTIVE from ACTIVE state without loss of allocated traffic.
Existing standards and implementations always assume that their peer signaling processes active for the application server are able to take any signaling traffic destined to the application server. This fact comes in conflict with SUA standard since one Signaling Process cannot be active for more than one TID or DRN label. Therefore, as soon as a signaling process becomes inactive other signaling processes cannot take over traffic destined to destination TIDs and DRNs defined by the TID and DRN labels of the inactive process and application server. For this reason the signaling process, which is going inactive, has to forward all non-allocated incoming traffic to other signaling processes capable of processing it as long as the process stays active although the loadsharing function is already in place at the remote signaling process.
An inactive signaling process, for example, ASP, is not able either to send nor receive any traffic from its peers (SGPs). For that reason an inactive process cannot perform test calls or any other maintenance related functions that require signaling communication with remote/distributed functional entities. However, once the signaling processes becomes active for an AS, it starts to receive the full range of new non-allocated traffic destined to the AS, although the purpose of activating the process was to perform only maintenance activities on the AS in the signaling process.
SUA standard does not define mechanisms to identify allocated/non-allocated traffic going towards SUA SGPs and does not define traffic management procedures dealing with corresponding call related stateful information at the SGPs.